Service de Détection de Pannes avec SNMP

Failure detection is an important issue of distributed programming. In a computer network, distinguishing a failed node from a slow one is difficult. Yet the difference is important for distributed applications: in the first case a reconfiguration is needed, in the second case, waiting is sufficient. Implementing efficient failure detection is difficult. Because of this, many applications use simplistic approaches like fixed timeouts. To address these issues, failure detection services have been proposed for some years. A service offers many advantages: a single implementation is shared by multiple applications, this implementation can be changed without rebuilding the application and complex failure detection techniques can be used without weighting down or increasing the complexity of the application. Many failure detection services have been proposed. But none is used outside of a small application niche. One of the reasons for this is that there is no standard for such a service. We present a failure detection service based on the SNMP (Simple Network Management Protocol) standard. SNMP is widely used for monitoring network infrastructure and servers. Our failure detection service uses SNMP for communication and application interfaces. This way, it can be interfaced using standard technologies and existing tools. Introduction : Une définition d'un système réparti a été donnée par Leslie Lamport : «Vous êtes en présence d'un système réparti si l'arrêt d'un ordinateur dont vous n'avez jamais entendu parler vous empêche de travailler». Elle illustre un des problèmes centraux dans les systèmes distribués: détecter et gérer les défaillances. Pour pouvoir tolérer des fautes, un mécanisme pour détecter les pannes de machines distantes est nécessaire. Au fur et à mesure que la taille et la complexité d'un système croissent, le besoin d'un système de détection de pannes devient une nécessité. Si la détection de pannes est un aspect important des systèmes répartis, la problématique est plus générale. Elle touche la gestion de réseau et de grappes de machines, le déploiement d'applications et l'informatique distribuée au sens large. S'il existe des solutions pour surveiller processus et nœuds, elles sont en général restreintes à des tâches de surveillance et de gestion. Au niveau applicatif, la détection de pannes se fait typiquement avec des timeouts (temps limites). L'approche par timeout n'est pas adaptée à la détection de pannes. Si l'on considère par exemple un client Web qui envoie une requête HTTP, un timeout durant la connexion peut signifier deux choses : le serveur est en panne, ou bien il est lent. L'utilisateur n'a aucune manière de distinguer ces deux cas à moins d’exécuter à nouveau la requête, ce qui n'est ni pratique, ni fiable. En fait, si le serveur est surchargé, cette nouvelle requête va simplement ajouter à la charge. Fixer le bon timeout est une tâche difficile, s'il est trop court, un serveur lent sera considéré comme défaillant, s'il est trop long, le client attendra inutilement la réponse d'un serveur en panne. Comme il n'existe pas de service de détection de pannes, les timeouts restent malheureusement la seule solution dans de nombreux cas. Un service de détection de pannes a pour but de remédier à ce problème. Les applications utilisent ce système pour décider si un processus distant est en panne, et, partant de là, elles se reconfigurent en cas de défaillances. Ce service peut-être utilisé directement par les applications, mais peut être utilisé par un middleware comme CORBA ou une infrastructure GRID. Finalement, ce service peut-être utilisé pour implémenter des détecteurs de fautes qui fournissent des propriétés formelles comme ◇S ou Ω[2]. Un service de détection offre de nombreux avantages. Premièrement il permet d'extraire une fonctionnalité complexe et par là de simplifier les applications. Deuxièmement l'implémentation, l'algorithme et le modèle sous-jacent peuvent être changés sans nécessiter de modification dans l'application. Troisièmement, ce service peut implémenter des techniques complexes qui ne seraient pas acceptables dans des applications – typiquement des approches adaptatives qui intègrent plusieurs sources d’information. Quatrièmement un service peut consolider les informations de monitoring de plusieurs applications en un seul flot, ce qui permet l’économie de messages. Si l’idée d’un service de détection de fautes n’est pas nouvelle, aucun des services proposés n’est utilisé en dehors de sa communauté d’origine. Souvent, les services ont été conçus pour servir à l’intérieur d’un projet ou d’un toolkit particulier. De ce fait, l’interopérabilité et l’intégration avec des standards existants n’a pas été une priorité. Un service sans interfaces standardisées a peu de chances d’être accepté à large échelle [1]. Le système SNMP-FD offre un service de détection de pannes qui cherche à remédier à ce défaut. Le service est basé sur un standard établi depuis plus de vingt ans dans le domaine de la gestion de l’infrastructure réseau et de la surveillance de serveurs critiques. L’utilisation du protocole SNMP nous offre plusieurs avantages : le protocole SNMP est un protocole léger, il nous permet d’interopérer avec les équipements réseau et d’autres services de gestion et de monitoring, enfin l’utilisation d’un standard existant nous évite d’en définir un nouveau, qui aurait de la peine à être accepté. Middleware : L’approche habituelle pour assurer l’interopérabilité dans les systèmes répartis est d’utiliser un middleware. Ces outils standardisent les interactions sur le réseau et le format des données. Plusieurs middlewares ont été envisagés pour ce projet, notamment CORBA et SOAP, mais SNMP est clairement l’outil le plus adapté : le protocole a été conçu pour des tâches de surveillance, permet de communiquer avec les équipements réseau, et une bonne partie des interfaces pour la surveillance de processus est déjà définie. De plus, étant conçu pour être embarqué sur du matériel réseau, c’est un protocole simple qui utilise des messages courts. Les autres middleware offrent des capacités et des abstractions bien plus avancées, mais qui, dans notre cas, ne sont pas utiles. SNMP : SNMP est un standard défini par l’IETF dans les années quatre-vingt-dix pour la gestion d’équipements réseau. De nos jours la grande majorité des équipements réseau (routeurs, passerelles, switches) ainsi que de nombreux périphériques connectés à travers le réseau (imprimantes), comportent un agent SNMP et peuvent donc êtres gérés en utilisant des outils standard. L’agent est l’entité logique responsable de surveiller un équipement et gérer les interactions SNMP. L’agent maintient une base de donnée, la Management Information Base (MIB), qui reflète l’état de l’agent et de l’équipement. La MIB est structurée en un arbre logique : chaque sous-arbre contient des données pertinentes à un domaine précis. Dans sa forme la plus simple, cette MIB ne contient qu’un sous-arbre avec des informations administratives (emplacement, responsable, etc.). De nombreux sous arbres ont été standardisé : allant de configuration et l’état des interfaces réseau jusqu’à l’état des bacs à papier d’une imprimante. Tous les éléments de la MIB peuvent être lus et dans certains cas, écrits. Un sous-arbre très important contient les tables de notification. Des processus distants peuvent y enregistrer leurs adresses afin de recevoir des messages asynchrones lors de changement d’états de l’équipement. Ces messages sont nommés trappes (trap). Ce mécanisme évite de devoir régulièrement interroger l’équipement pour savoir si son état a changé. SNMP-FD : Le service de détection de fautes SNMP-FD est conçu d’entrée pour être utilisé dans des contextes multiples et à travers une interface standard. Il est intégralement construit sur le standard SNMP. Il utilise ce standard deux manières. Premièrement, les interfaces du service sont exposées suivant le standard SNMP : l’état du service est accessible via la MIB et les suspicions de pannes sont délivrées par le biais de trappes. Les informations propres à un service de détection de pannes sont définies dans des sous-arbres spéciaux, mais une grande partie de l’information (état des processus, enregistrement des entités désirant recevoir des notifications) est stockée dans des sous-arbres standard. Notre outil est donc compatible avec les outils de monitoring et d’administration réseau existants. Deuxièmement, le service est construit en utilisant les mécanismes offerts par le protocole SNMP. Les messages entre les différents nœuds sont des messages SNMP. En particulier, un aspect important de l’implémentation d’un service de détection de pannes est l’envoi de messages de heartbeat, ces messages sont échangés périodiquement entre les nœuds afin de vérifier que chaque nœud n’est pas défaillant. Ces messages sont implémentés au moyen de trappes SNMP. L’avantage de cette approche c’est que les trappes SNMP ont été conçues pour minimiser la charge réseau : une trappe est transmise grâce à un seul message UDP. Le service SNMP-FD est conçu de manière à permettre en son sein l’implémentation des diverses politiques de détection de pannes décrites dans la littérature. Toutes ces techniques de détection partagent une infrastructure commune fournie par notre système. De plus, l’intégration avec le protocole SNMP permet d’utiliser non seulement des messages de heartbeat, mais aussi des informations extraites de l’équipement réseau, ces informations aident à améliorer la qualité du service [3]. Par exemple, si une machine tombe en panne, son interface réseau sera désactivée. Cet événement sera détecté par le switch auquel la machine est connectée et annoncé au moyen d’une trappe. L’utilisation de ces informations avancées permet d’augmenter la qualité du service de détection sans augmenter la fréquence d’envoi des messages de heartbeat, en effet, ceux-ci tendent à surcharger le réseau s’ils sont envoyés à une trop grande fréquence.